크로스 오리진 통신: PostMessage API를 사용한 보안 패턴

현대 웹에서 애플리케이션은 종종 다른 출처의 리소스와 상호 작용해야 합니다. 동일 출처 정책(Same-Origin Policy, SOP)은 스크립트가 다른 출처의 리소스에 접근하는 것을 제한하는 중요한 보안 메커니즘입니다. 그러나 크로스 오리진 통신이 합법적으로 필요한 시나리오도 있습니다. postMessage API는 이를 달성하기 위한 제어된 메커니즘을 제공하지만, 잠재적인 보안 위험을 이해하고 적절한 보안 패턴을 구현하는 것이 중요합니다.

동일 출처 정책(SOP) 이해하기

동일 출처 정책은 웹 브라우저의 기본 보안 개념입니다. 이는 웹 페이지가 해당 웹 페이지를 제공한 도메인과 다른 도메인으로 요청하는 것을 제한합니다. 출처는 스킴(프로토콜), 호스트(도메인), 포트로 정의됩니다. 이 중 하나라도 다르면 다른 출처로 간주됩니다. 예를 들어:

• https://example.com
• https://www.example.com
• http://example.com
• https://example.com:8080

이들은 모두 다른 출처이며, SOP는 이들 간의 직접적인 스크립트 접근을 제한합니다.

PostMessage API 소개

postMessage API는 안전하고 제어된 크로스 오리진 통신 메커니즘을 제공합니다. 이를 통해 스크립트는 출처에 관계없이 다른 창(예: iframe, 새 창 또는 탭)으로 메시지를 보낼 수 있습니다. 수신 창은 이러한 메시지를 수신하고 그에 따라 처리할 수 있습니다.

메시지를 보내는 기본 구문은 다음과 같습니다:

otherWindow.postMessage(message, targetOrigin);

• otherWindow: 대상 창에 대한 참조 (예: window.parent, iframe.contentWindow, 또는 window.open에서 얻은 창 객체).
• message: 보내려는 데이터입니다. 직렬화할 수 있는 모든 JavaScript 객체가 가능합니다 (예: 문자열, 숫자, 객체, 배열).
• targetOrigin: 메시지를 보내려는 출처를 지정합니다. 이는 중요한 보안 매개변수입니다.

수신 측에서는 message 이벤트를 수신 대기해야 합니다:

window.addEventListener('message', function(event) {
  // ...
});

event 객체에는 다음과 같은 속성이 포함됩니다:

• event.data: 다른 창에서 보낸 메시지.
• event.origin: 메시지를 보낸 창의 출처.
• event.source: 메시지를 보낸 창에 대한 참조.

보안 위험 및 취약점

postMessage는 SOP 제한을 우회하는 방법을 제공하지만, 신중하게 구현하지 않으면 잠재적인 보안 위험을 초래할 수도 있습니다. 일반적인 취약점은 다음과 같습니다:

1. 대상 출처 불일치

event.origin 속성을 검증하지 않는 것은 심각한 취약점입니다. 수신자가 메시지를 맹목적으로 신뢰하면 어떤 웹사이트든 악의적인 데이터를 보낼 수 있습니다. 메시지를 처리하기 전에 항상 event.origin이 예상 출처와 일치하는지 확인해야 합니다.

예시 (취약한 코드):

window.addEventListener('message', function(event) {
  // 이렇게 하지 마세요!
  processMessage(event.data);
});

예시 (안전한 코드):

window.addEventListener('message', function(event) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('신뢰할 수 없는 출처로부터 메시지 수신:', event.origin);
    return;
  }

  processMessage(event.data);
});

2. 데이터 주입

수신된 데이터(event.data)를 실행 가능한 코드로 취급하거나 DOM에 직접 주입하면 사이트 간 스크립팅(XSS) 취약점으로 이어질 수 있습니다. 수신된 데이터는 사용하기 전에 항상 살균(sanitize)하고 검증해야 합니다.

예시 (취약한 코드):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    document.body.innerHTML = event.data; // 이렇게 하지 마세요!
  }
});

예시 (안전한 코드):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    const sanitizedData = sanitize(event.data); // 적절한 살균 함수를 구현하세요
    document.getElementById('message-container').textContent = sanitizedData;
  }
});

function sanitize(data) {
    // 여기에 강력한 살균 로직을 구현하세요.
    // 예를 들어, DOMPurify 또는 유사한 라이브러리를 사용하세요
    return DOMPurify.sanitize(data);
}

3. 중간자(MITM) 공격

안전하지 않은 채널(HTTP)을 통해 통신이 이루어지면 MITM 공격자가 메시지를 가로채고 수정할 수 있습니다. 안전한 통신을 위해 항상 HTTPS를 사용하십시오.

4. 사이트 간 요청 위조(CSRF)

수신자가 적절한 검증 없이 수신된 메시지를 기반으로 작업을 수행하면 공격자가 메시지를 위조하여 수신자가 의도하지 않은 작업을 수행하도록 속일 수 있습니다. 메시지에 비밀 토큰을 포함하고 수신 측에서 이를 확인하는 등 CSRF 보호 메커니즘을 구현하십시오.

5. targetOrigin에 와일드카드 사용

targetOrigin을 *로 설정하면 모든 출처가 메시지를 수신할 수 있습니다. 이는 출처 기반 보안의 목적을 무력화하므로 절대적으로 필요한 경우가 아니면 피해야 합니다. *를 사용해야 하는 경우, 메시지 인증 코드(MAC)와 같은 다른 강력한 보안 조치를 구현해야 합니다.

예시 (피해야 할 코드):

otherWindow.postMessage(message, '*'); // 절대적으로 필요한 경우가 아니면 '*' 사용을 피하세요

보안 패턴 및 모범 사례

postMessage와 관련된 위험을 완화하려면 다음 보안 패턴 및 모범 사례를 따르십시오:

1. 엄격한 출처 검증

수신 측에서 항상 event.origin 속성을 검증하십시오. 미리 정의된 신뢰할 수 있는 출처 목록과 비교하십시오. 비교에는 엄격한 동등성(===)을 사용하십시오.

2. 데이터 살균 및 검증

postMessage를 통해 수신된 모든 데이터는 사용하기 전에 살균하고 검증하십시오. 데이터가 사용될 방식에 따라 적절한 살균 기술(예: HTML 이스케이핑, URL 인코딩, 입력 검증)을 사용하십시오. HTML 살균을 위해 DOMPurify와 같은 라이브러리를 사용하십시오.

3. 메시지 인증 코드(MAC)

메시지의 무결성과 신뢰성을 보장하기 위해 메시지에 메시지 인증 코드(MAC)를 포함시키십시오. 발신자는 공유 비밀 키를 사용하여 MAC을 계산하고 메시지에 포함합니다. 수신자는 동일한 공유 비밀 키를 사용하여 MAC을 다시 계산하고 수신된 MAC과 비교합니다. 일치하면 메시지는 신뢰할 수 있고 변조되지 않은 것으로 간주됩니다.

예시 (HMAC-SHA256 사용):

// 발신자
async function sendMessage(message, targetOrigin, sharedSecret) {
  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(message));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  const securedMessage = {
    data: message,
    signature: signatureHex
  };

  otherWindow.postMessage(securedMessage, targetOrigin);
}

// 수신자
async function receiveMessage(event, sharedSecret) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('신뢰할 수 없는 출처로부터 메시지 수신:', event.origin);
    return;
  }

  const securedMessage = event.data;
  const message = securedMessage.data;
  const receivedSignature = securedMessage.signature;

  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(message));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  if (signatureHex === receivedSignature) {
    console.log('메시지가 신뢰할 수 있습니다!');
    processMessage(message); // 메시지 처리 진행
  } else {
    console.error('메시지 서명 검증 실패!');
  }
}

중요: 공유 비밀 키는 안전하게 생성되고 저장되어야 합니다. 코드에 키를 하드코딩하지 마십시오.

4. Nonce와 타임스탬프 사용

재전송 공격을 방지하기 위해 메시지에 고유한 nonce(한 번 사용되는 숫자)와 타임스탬프를 포함시키십시오. 수신자는 nonce가 이전에 사용되지 않았는지, 그리고 타임스탬프가 허용 가능한 시간 프레임 내에 있는지 확인할 수 있습니다. 이는 공격자가 이전에 가로챈 메시지를 재전송하는 위험을 완화합니다.

5. 최소 권한 원칙

다른 창에는 최소한의 필요한 권한만 부여하십시오. 예를 들어, 다른 창이 데이터 읽기만 필요하다면 데이터 쓰기를 허용하지 마십시오. 최소 권한 원칙을 염두에 두고 통신 프로토콜을 설계하십시오.

6. 콘텐츠 보안 정책(CSP)

콘텐츠 보안 정책(CSP)을 사용하여 스크립트를 로드할 수 있는 소스와 스크립트가 수행할 수 있는 작업을 제한하십시오. 이는 postMessage 데이터의 부적절한 처리로 인해 발생할 수 있는 XSS 취약점의 영향을 완화하는 데 도움이 될 수 있습니다.

7. 입력 검증

수신된 데이터의 구조와 형식을 항상 검증하십시오. 명확한 메시지 형식을 정의하고 수신된 데이터가 이 형식에 부합하는지 확인하십시오. 이는 예기치 않은 동작과 취약점을 예방하는 데 도움이 됩니다.

8. 안전한 데이터 직렬화

메시지를 직렬화하고 역직렬화하기 위해 JSON과 같은 안전한 데이터 직렬화 형식을 사용하십시오. eval()이나 Function()과 같이 코드 실행을 허용하는 형식은 사용하지 마십시오.

9. 메시지 크기 제한

postMessage를 통해 보내는 메시지의 크기를 제한하십시오. 큰 메시지는 과도한 리소스를 소비하고 잠재적으로 서비스 거부 공격으로 이어질 수 있습니다.

10. 정기적인 보안 감사

잠재적인 취약점을 식별하고 해결하기 위해 코드에 대한 정기적인 보안 감사를 수행하십시오. postMessage 구현에 세심한 주의를 기울이고 모든 보안 모범 사례가 준수되었는지 확인하십시오.

예시 시나리오: Iframe과 부모 페이지 간의 안전한 통신

https://iframe.example.com에 호스팅된 iframe이 https://parent.example.com에 호스팅된 부모 페이지와 통신해야 하는 시나리오를 고려해 보겠습니다. iframe은 처리를 위해 사용자 데이터를 부모 페이지로 보내야 합니다.

Iframe (https://iframe.example.com):

// 공유 비밀 키 생성 (안전한 키 생성 방법으로 대체)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

// 사용자 데이터 가져오기
const userData = {
  name: 'John Doe',
  email: 'john.doe@example.com'
};

// 부모 페이지로 사용자 데이터 전송
async function sendUserData(userData) {
  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(userData));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  const securedMessage = {
    data: userData,
    signature: signatureHex
  };
  parent.postMessage(securedMessage, 'https://parent.example.com');
}

sendUserData(userData);

부모 페이지 (https://parent.example.com):

// 공유 비밀 키 (iframe의 키와 일치해야 함)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

window.addEventListener('message', async function(event) {
  if (event.origin !== 'https://iframe.example.com') {
    console.warn('신뢰할 수 없는 출처로부터 메시지 수신:', event.origin);
    return;
  }

  const securedMessage = event.data;
  const userData = securedMessage.data;
  const receivedSignature = securedMessage.signature;

  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(userData));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');


  if (signatureHex === receivedSignature) {
    console.log('메시지가 신뢰할 수 있습니다!');
    // 사용자 데이터 처리
    console.log('사용자 데이터:', userData);
  } else {
    console.error('메시지 서명 검증 실패!');
  }
});

중요 참고사항:

• YOUR_SECURE_SHARED_SECRET을 안전하게 생성된 공유 비밀 키로 교체하십시오.
• 공유 비밀 키는 iframe과 부모 페이지 모두에서 동일해야 합니다.
• 이 예제는 메시지 인증을 위해 HMAC-SHA256을 사용합니다.

결론

postMessage API는 웹 애플리케이션에서 크로스 오리진 통신을 가능하게 하는 강력한 도구입니다. 그러나 잠재적인 보안 위험을 이해하고 이러한 위험을 완화하기 위해 적절한 보안 패턴을 구현하는 것이 중요합니다. 이 가이드에서 설명한 보안 패턴과 모범 사례를 따르면 postMessage를 안전하게 사용하여 견고하고 안전한 웹 애플리케이션을 구축할 수 있습니다.

항상 보안을 최우선으로 생각하고 웹 개발을 위한 최신 보안 모범 사례를 숙지하십시오. 애플리케이션이 잠재적인 취약점으로부터 보호되도록 정기적으로 코드와 보안 구성을 검토하십시오.